lunedì, febbraio 23, 2009

Transparent proxy con IPCop

Alla luce dei problemi visti con router e stateful firewall, l'unica soluzione che rimane per controllare il problema della distribuzione di Internet alla rete locale è quella di usare un proxy, magari in modalità trasparente per evitare di dover configurare tutti client o distribuire il WPAD.
Si trova in Rete una soluzione comoda ed efficace che ci permette di usare un proxy Squid senza perdere molto tempo per la configurazione, e che integra controllo degli accessi e del traffico e molte altre features che possono essere aggiunte con comodi plugin. La soluzione in questione è IPCop.
La comodità di tale software sta tutta nella velocità di implementazione: infatti il sistema una volta installato è pronto e funzionante, e basta aggiungere i plugin desiderati.
IPCop usa Linux 2.4, IPTABLES, Squid (già presenti nell'installazione di default), SquidGuardian, ClamAV e altri ancora, a seconda dei plugin installati.
Come plugins consiglio di dare un'occhiata al sito mhaddons che contiene, nella sezione Downloads, una serie di aggiunte quasi indispensabili. Fra queste i filtri layer 7, utili nel caso si voglia usare il traffic shaping a livello di protocollo applicazione o se si vuole bloccare certi tipi di traffico (es. il P2P, vedi "p2pblock" in mhaddons). Nel caso si vogliano installare i filtri è necessario sostituire il kernel di IPCop con uno che li integra. Istruzioni nel sito alla pagina Layer7 blocker.

C'è da osservare che la scelta di bloccare il P2P non si rivela molto efficace a causa della scarsa efficenza dei pattern di riconoscimento.

martedì, febbraio 03, 2009

Staful firewall: pro e contro


Gli stateful firewall sono dei firewall che operano a livello 4 della pila ISO-OSI, cioè consentono di specificare delle regole che coinvolgono tipo di protocollo (TCP, UDP, ICMP, ecc.) e porta di origine o destinazione. In uno dei precedenti articoli in questo blog abbiamo visto come implementare una soluzione simile in RRAS di Windows Server. La soluzione proposta aveva queste caratteristiche:
- efficace contro le connessioni a server di P2P come Emule;
- meno efficace nel contrastare le connessioni peer nel P2P (ad es. rete Kad o Bittorrent);
- efficace nel filtrare tutti i tipi di pacchetti acconsentendo il traffico solo attraverso le porte note;
- poco efficace nel protocollo FTP in passive mode, dato che le porte dati sono scelte random fra le PASV (1025-65535).

Visti questi pregi e difetti, la caratteristica più appariscente all'utente finale era sicuramente il mancato accesso all'FTP, sia con programmi dedicati che da browser.

Il problema, usando uno stateful firewall (e anche RRAS), non è risolvibile, a meno di rinunciare alla sicurezza della rete...

Si può considerare un proxy come Squid come valida alternativa, ma quest'ultimo lascia passare comunque i P2P. Nel prossimo articolo vedremo una soluzione basata su L7filter, programma che opera a livello sette della pila OSI e che permette quindi di intervenire nei protocolli "applicativi" come HTTP, POP3, FTP, ecc.

A presto!

sabato, gennaio 24, 2009

Thinstation: istruzioni per l' uso


Thinstation è un prodotto open source che permette la trasformazioni di computer un po' datati in terminali.

Il suo utilizzo è piuttosto semplice, a patto che si conosca già abbastanza bene il funzionamento di Linux e dei servizi terminale. Questo articolo illustra brevemente come impostare un'installazione di Thinstation in uno scenario tipico. Cosa da far notare prima di iniziare è che nessuna delle macchine virtuali attualmente sul mercato hanno schede di rete compatibili con Etherboot e Thinstation in genere, quindi bisogna escludere da subito il testing in VM.

Lo scenario considerato è il seguente:
- si usa Windows Terminal Services;
- i pc posseggono lettore floppy e lettore CD-Rom;
- abbiamo Windows Server con servizio Microsoft DHCP attivo;
- un pc con Linux per compilare le immagini di TS.
Vogliamo avviare i pc con TS da rete e farli connettere al server Windows via RDP.

1 - PREPARAZIONE
Procurarsi Thinstation 2.2.2 (attualmente è la versione stabile) da qui; in circa 50MB abbiamo tutto l'occorrente. Da un installazione di Linux scompattiamo il pacchetto. Nella cartella che otteniamo troveremo un file build.conf che serve per configurare i pacchetti hardware delle macchine in questione.
Prima di compilare il tutto ed ottenere le nostre immagini di avvio, dobbiamo raccogliere alcuni dati indispensabili dai pc su cui vogliamo far girare TS:
- marca e modello scheda di rete;
- marca e modello scheda video;
- marca e modello chipset;
- mac address scheda di rete;
- assicurasi che la ram sia almeno 64MB, in caso contrario TS non si avvia.
Per la raccolta di questi dati consiglio Everest Portable (thanks to Bert).

Scrivere il file build.conf come da esempi nella stessa cartella, aggiungendo i pacchetti che servono. Oltre a questi mettiamo anche il pacchetto rdesktop, che gestisce la connessione RDP.

NB: per la redirection delle chiavette usb, che si vedranno da Esplora risorse. E' necessario includere i pacchetti "supermount" e "automount", oltre cha naturalemnte "usb-hid".
Compiliamo tutto eseguendo il comando da terminale "./build".

Nella cartella "boot-files/etherboot" troveremo i due file che ci servono per il boot da rete tramite Etherboot, nelle altre cartelle ci sono le immagini per boot per altri supporti (cdrom) e metodi (PXE, syslinux, ecc.).

2 - BOOT
Per consentire il boot da rete via Etherboot occuperemo il disco floppy delle macchine client scrivendo l'immagine Etherboot che TS ci fornisce nella cartella "prebuild". L'immagine da 32KB serve a forzare il boot da rete anche da pc che non lo supportano.
Inoltre abbiamo bisogno di settare un server TFTP (è un protocollo molto grezzo per l'invio delle immagini di boot via rete); useremo per questo Solarwind TFTP server (gratuito), settando anche che il server è in sola lettura (NB: la porta in uscita di questo server è la 69 UDP, settate di conseguenza eventuali firewall).
Nella cartella che setteremo come radice TFTP metteremo i file thinstation.nbi e thinstation.nbi.zpxe trovati dopo la compilazione in "boot-files/etherboot".
Nella MMC del DHCP inoltre, in Opzioni Ambito, attiveremo le voci 066 e 067 rispettivamente con l'indirizzo ip del server e il nome del file di boot "thinstation.nbi.zpxe".

N.B.: alcune guide indicano che per Etherboot bisogna settare nel DHCP il file "thinstation.nbi", ma noi vogliamo anche la compatibilità con PXE.

3 - CONFIGURAZIONE DI TS
Si riporta qui di seguito una configurazione funzionante in molti casi:
NET_USE_DHCP=On

KEYBOARD_MAP=it
USB_ENABLED=On
CUSTOM_CONFIG=Off
RECONNECT_PROMPT=On

SESSION_0_TITLE="Terminale 1"
SESSION_0_TYPE=rdesktop
SESSION_0_SCREEN=1
SESSION_0_RDESKTOP_SERVER=192.168.1.17
# con redirect delle chivette usb
SESSION_0_RDESKTOP_OPTIONS="-u 'DOMINIO\\\\utente' -r disk:usb=/mnt/usbdevice,sound:off"
SESSION_0_AUTOSTART=On

SCREEN_RESOLUTION="1280x1024"
SCREEN_COLOR_DEPTH="16"
SCREEN_BLANK_TIME=10
SCREEN_STANDBY_TIME=20
SCREEN_SUSPEND_TIME=30
SCREEN_OFF_TIME=60

X_DRIVER_OPTION1="hwcursor Off"

NET_HOSTNAME=Nomepc

Le voci si spiegano da sè; inoltre in thinstation.conf.sample è tutto ben documentato. Abbiamo molte possibilità per come e dove piazzare i file di configurazione, io preferisco farne uno per ogni macchina che si carichi da rete quando la stessa si avvia.
Per fare questo settiamo delle prenotazioni di IP nel server DHCP (inserendo il mac address della scheda) e piazziamo nella root del server TFTP dei file con nomi di questo tipo "thinstation.conf-192.168.1.11", in modo da controllare la configurazione di ogni macchina semplicemente modificando un file di configurazione nel server. Il file viene letto solo all'avvio di TS.

Si segnala infine un altro prodotto simile: Netstation, che è meno flessibile e meno potente ma più leggero, da prendere quindi in seria considerazione se la ram dei terminali è molto bassa (anche 8MB).

venerdì, gennaio 23, 2009

Thin client: guida alla scelta

Un thin client è un pc trasformato in un terminale. La conversione conviene quando il pc è obsoleto o manca di parti importanti (come l'hard disk). Dove si usano i thin client?
1 - nelle aziende che, avendo a disposizione un server ben equipaggiato, hanno bisogno di molte postazioni per i dipendenti, le quali non compiono operazioni complesse o pesanti;
2 - nelle scuole, per risparmiare sull'hardware e mantenere uno stretto controllo;
3 - in tutti quei casi in cui i pc vecchi con qualche acciacco hardware abbondano.

RETE:
Come agli albori dell'informatica, lo scenario tipico prevede che il terminale (thin pc) si connetta via rete (cablata preferibilmente) con un server, che fornisce una console o interfaccia grafica "spedita" via rete.
Per il dimensionamento dell'infrastruttura di rete tenere conto che l'uso di larghezza di banda è elevato (sconsigliato quindi il wireless) e che è importante l'uso di switch anzichè di hub per evitare al massimo le collisioni di pacchetti.

SERVER:
Per la scelta del server c'è solo da dire che lato Windows l'unica alternativa disponile è usare Terminal Services (implementazione del protocollo RDP), mentre per Linux le alternative sono molte, ma la preferibile secondo me resta la sessione X.
Ovviamente il server deve essere dimensionato per sostenere tutte le utenze simultanee (i parametri principali sono processore e spazio su disco).

LICENZE:
Per Windows usare Terminal Services costa quasi quanto un'installazione locale del sistema operativo. Per le scuole Microsoft da licenze CAL TS nella versione EDU a un quarto del prezzo commerciale. Le CAL TS richiedono sempre la resenza di una versione server di Windows, escluso Small Business.
C'è un'interessante alternativa nel prodotto Terminal services PRO di Elusiva, che permette di usare Windows XP per ottenere 5 terminali, allo stesso modo di Widnows Server, ma senza il costo della sua licenza e delle 5 CAL TS. Il prezzo di questo prodotto si aggira sui 250$.

sabato, dicembre 27, 2008

Installazione lingua italiana in Windows Server 2008

Windows Server 2008 non è disponibile in italiano. Microsoft mette a disposizione dei Language Packs per installare successivamente la lingua desiderata, come accade in Windows Vista Ultimate. I language pack si scaricano dal sito di Microsoft in un'immagine IMG, che contiene delle cartelle per gruppi di lingue indicati nel sito: ad esempio il file che contiene l'italiano è il numero 4 e il gruppo di appertenenza è il 3.
Microsoft riporta la guida per integrare i language pack nel DVD di installazione di WIndows Server, ma nella stragrande maggioranza delle installazioni server di piccole dimensioni avremo bisogno di installare la lingua aggiuntiva in un'installazione già funzionante.
Per fare questo basta digitare da Start\Run... il comando lpksetup, indicare la posizione del file LP.cab che ci serve (estratto preventivamente dalla IMG) e l'installazione procede automaticamente. Dopo il aver eseguito di nuovo il logon, ecco l'interfaccia di Windows Server nella lingua desiderata.

venerdì, dicembre 26, 2008

Errore Sysfader

Può capitare che utilizzando Internet Explorer 7 si incappi in un fastidiosi errore di esecuzione del programma stesso che obbliga a terminarlo. L'errore si presenta più o meno così:
SysFader: iexplorer.exe - Errore di applicazione
L'istruzione a "0x300a2074" ha fatto riferimento alla memoria a "0x05b3de24" . La memoria non poteva essere "read".

L'errore avviene sia dentro IE7, sia alla sua chiusura, sia quando si sta iniziando un download, sia all'esterno di IE, come ad es. in Firefox. La documentazione in Internet è molto varia e spesso le soluzioni proposte non risolvono il problema. Ecco invece tre consigli per risolverlo definitivamente:
  1. disabilitare Attiva transizione di pagina in IE7 da Strumenti/Opzioni Internet/Avanzate e poi riavviare IE;
  2. settare "Regola in modo da ottenere le prestazioni migliori" da Pannello di Controllo/Sistema/Avanzate/Prestazioni;
  3. (più importante) disattivare in IE7 tutti i plugin relativi a SharePoint da da Strumenti/Opzioni Internet/Componenti Aggiuntivi. L'errore di sysfader accade infatti quando c'è un conflitto di versione fra Office v11 e v12 installati sulla stessa macchina (anche solo se sono installati alcuni componenti di Office, non occorre un'installazione completa).

giovedì, novembre 06, 2008

Registrare online un canale TV

Per poter registrare online un canale TV si può usare il sito gratuito VCast .
Alla voce FaucetPVR infatti è possibile selezionare un canale e un intervallo di tempo in cui registrare il nostro programma preferito, scaricabile poi comodamente in diversi formati (iPod, DivX, OGG, MP3, ecc.). Il filmato viene mantenuto sul server per un massimo di tre giorni dalla fine della registrazione. Il sito permette, allo stesso modo, di fare ciò anche con i canali radio.

venerdì, agosto 22, 2008

Grafici con Google Chart

Google mette a disposizione di tutti gli utenti della Rete un servizio per comporre dei grafici a partire da dataset dell'utente inseribili senza sforzo in pagine web. Basta leggere le istruzioni su come scrivere la stringa per richiedere il grafico e il gioco è fatto. Per chi non volesse programmare i propri grafici allora esiste un tool che permette la costruzione automatica dell'URL all'indirizzo http://www.clabberhead.com/googlechartgenerator.html .

domenica, maggio 25, 2008

Linux Terminal Services


Per poter accedere a Linux da macchine Windows consiglio il tool Xming, che permette la connessione attraverso XDMCP e SSH all'interfaccia grafica di Linux (porte 177 e 22 rispettivamente). Nell'installazione di Linux deve essere abilitato l'accesso (in Gnome è possibile farlo dal pannello "Finestra di login") e deve essere installato un server SSH specialmente se si vuole far girare applicazioni remote come una finestra Windows locale. Da provare, molto comodo e veloce: l'utilizzo di banda di rete è alto (circa 5 volte un RDP) ma la visualizzazione non soffre dei rallentamenti tipici dei Windows RD. Ad es. in Ubuntu, usando il gestore degli accessi GDM (di Gnome), ci può essere qualche problema se nella stessa macchina coesiste anche KDE4 (tipico invece di Kubuntu). Dal lato Windows, un problema non risolto è che anche il nome utente durante l'accesso viene visualizzato con dei pallini, come la password. Una possibile soluzione è installare in Windows il certificato del server SSH.

Ubuntu Wubi


La distribuzione di Linux Ubuntu è molto probabilmente la più matura per quanto riguarda la facilità d'uso. Nell'intenzione di venire sempre più incontro all'utente finale e facilitare la migrazione da Windows, la versione 8.04 (Hardy Heron) è dotata di un tool chiamato Wubi, che permette l'installazione di Ubuntu in PC senza dover partizionare il disco. Inoltre, sfruttando il boot manager di Windows, viene inserita una voce che permette di avviare Linux. I file di sistema sono ospitati da un'immagine del disco rigido che vive come semplice file in NTFS. Proprio una bella trovata!

venerdì, aprile 18, 2008

Tool di videoconferenza

Attualmente per chi cerca un tool di video conferenza online, Yugma è l'offerta meglio progettata: con la versione base basta iscriversi nel sito e si possono creare sessioni di conferenza con la condivisione del proprio desktop.

Se invece gestite un server e cercate una soluzione open per fare videoconferenza, vi consiglio DimDim, che è anche utilizzabile come il primo solo online.

lunedì, marzo 10, 2008

VPN over the Internet

Vorrei segnalare con questo articolo la presenza di un tool molto utile per creare facilmente delle VPN in Internet. Lo strumento in questione si chiama Hamachi, ed esiste nelle versioni per Windows, Linux e Mac OS X. La facilità di gestione delle VPN è impressionante... da provare.

sabato, febbraio 02, 2008

Profili utente in un dominio Windows

A causa della documentazione confusa e a tratti insufficiente di Microsoft, ecco un articolo per partire con la configurazione dei desktop degli utenti dei pc in rete in un dominio Windows.
Alcune premesse:
- è possibile permettere o negare l'accesso con lo stesso account utente da più macchine contemporaneamente (e l'accesso simultaneo è utile se non serve che gli utenti si logghino ogni volta che usano il pc - ad es. sale internet per piccole e medie strutture);
- tutte le porte TCP/IP del server verso la rete locale devono essere aperte, poichè la trasmissione del profilo di Windows necessita alcune porte per l'RPC scelte a caso dopo la 1024, e forzarle è difficile (si interviene sui servizi componenti DCOM) e sconveniente(altri servizi di Windows non funzionano - ad es. alcune istanze fondamentali di svchost.exe);
- gli account del gruppo Domain Admins possono aggiungere e togliere pc dal dominio, mentre se fanno parte di Administrators allora possono anche operare sulle macchine a fondo e accedere al server!);
- gli oggetti computer in un dominio vengono creati automaticamente al primo accesso, gli utenti ovviamente no.

Per incominciare installare nel server la Group Policy Management Console, scaricabile da qui.
Una volta installata potete definire delle policies nuove, oltre a quelle di default già presenti, con il tasto destro sulla voce interessata nel menu a sinistra. La policy entra in funzione quando è "linkata" al dominio. E' possibile settare policies concorrenti, ma consiglio non farlo perchè in tal caso bisogna accuratamente controllare la precedenza. E' meglio associare a ogni policy il gruppo utente desiderato. Per associarla a tuttio gli utenti, aggungere solo Autenticated Users.
Per editare le policy, tasto dx sulla voce relativa del menu a sx e scegliere Edit. Non descrivo qui ogni singolo gruppo di voci perchè è presente una descrizione dettagliata nella console. Sappiate subito che è possibile anche distribuire pacchetti di installazione in formato msi.
Consiglio fortemente di togliere il link dal dominio delle Default Policies e applicare quelle nuove non cancellando le vecchie.

Infine, se qualche pc avesse problemi a creare il profilo locale con l'utente del dominio e desse errori del tipo "Impossibile copiare..." ad ogni tentativo di accesso, allora c'è qualche file corrotto in C:\Documents and Settings\Default User. Salvate da un'altra parte il contenuto della cartella e copiateci dentro il contenuto della cartella di qualsiasi altro utente, eccetto quello in uso e All Users. Loggate poi l'utente e lasciate al pc il tempo di ricostruire il profilo (anche un'ora).
Le informazioni in questa ultima parte dell'articolo valgono per Windows 2000 e Windows XP Professional.

Configurare il DNS per il dominio

Con il comando "dcpromo" di Windows Server viene installato il servizio di Active Directory e si creano le impostazioni nel DNS per l'ingresso in dominio dei pc in rete. Nello specifico il DNS contiene due "zone":
- una con il nome del dominio;
- un'altra con il nome _msdcs.dominio .

La seconda serve per dire ai client dove si trova il servizio LDAP e altri supporti di Active Directory necessari per i pc in rete. Se per caso la cartella non ci fosse o fosse stata cancellata per sbaglio, allora ricreare la zona con il nome _msdcs.dominio e lasciarla vuota (è quasi impossibile ricreare tutte le voci a mano, magari copiandole da un'altra installazione di Windows Server, anche perchè ce n'è almeno una con una stringa esadecimale univoca che identifica il dominio). Infine riavviare il servizio Netlogon (net stop netlogon e poi net start netlogon) e attendere diversi minuti. Al termine dell'attesa ritrovere la zona _msdcs.dominio completa e funzionante.

Infine alcune osservazioni: lanciando dcpromo, se il DNS non è presente nel server, viene installato. Inoltre è possibile, in presenza di un IP fisso nella connessione a Internet, creare un dominio di terzo livello associato all'IP e usarlo nella creazione del dominio. Il wizard di configurazione del DNS darà qualche errore nella schermata di test, che si può tranquillamente ignorare (l'errore è dovuto sostanzialmente al fatto che non il server DNS del servizio che si usa per registrare il nome, DynDns ad esempio, non sa e non permette che il vostro server sia a sua volta un controller di dominio di sottozona delegata). Consiglio (ed è praticamente obbligatorio), nello scenario di rete appena esposto, di usare dei server d'inoltro delle richieste DNS affidabili, e se non volete usare i server del vostro ISP, allora usate OpenDNS (vedi articolo relativo in questo blog).

sabato, gennaio 19, 2008

Porte di MSN e Live Messenger


MSN Messenger (fino alla versione 7.5, ultima compatibile con Windows 2000) usa le seguenti porte:
  • 1863 TCP e UDP per i messaggi ed il log in;
  • 6891-6900 TCP per scambio file (max 10, uno per porta);
  • 5190 UDP
  • 6901 TCP+TCP per la voce

Windows Live Messenger (versioni 8.0,8.1 e 8.5) usa invece:

  • 1863 TCP e UDP per i messaggi ed il log in;
  • 6891-6900 TCP per scambio file (max 10, uno per porta);
  • 12352 UDP
  • 6901 TCP+TCP per la voce
  • 14300 TCP
  • 7790 UDP
La serie di porte 6891-6900 TCP serve per lo scambio file, e, se desiderate permettere un solo scambio file per utente nella rete privata, aprite solo la prima porte, cioè la 6891; per due scambi simultanei anche la seconda e così via.

Filtri IP "trasparenti"


Abitualmente si consiglia di non promuovere controller di dominio un server che fa già il routing fra reti, ma per chi avesse una disponibilità limitata di macchine e di spesa, c'è la soluzione per la buona convivenza dei due servizi.
Prendiamo in considerazione Windows Server 2003, ma la soluzione qui spiegata funziona sia sul predecessore (Windows 2000 Server) sia sul successore (Windows Server 2008).

Per fare si che i pc entrino in dominio le porte del controller di dominio verso la rete locale devono essere tutte aperte e il DNS deve pubblicare l'indirizzo IP locale.
Per configurare correttamente il DNS bisogna aggiungere alòò registro di sistema le chiavi:
  • Value name: PublishAddresses
    Data type: REG_SZ
    Value data: IP address of the server's local network adapter. If you have to specify more than one IP address, separate the addresses with spaces.
    IN
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\...
    DNS\Parameters
  • Value name: RegisterDnsARecords
    Data type: REG_DWORD
    Value data: 0
    IN
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\...
    Netlogon\Parameters
Riavviare quindi il servizio DNS.
Ora dobbiamo aggiungere (se non è gia esistente) il record A nel DNS che contiene l'indirizzo IP interno del server: clicchiamo sul nome del nostro dominio in Forward Lookup Zones e dal menu Azioni selezioniamo New Host (A)... . Lasciare il nome dell'host vuoto, inserire l'ip interno e cliccare anche su Create Associated PTR Record e dare OK. Nella stessa cartella facciamo la stessa cosa sotto MSDCS \ GC. Ignorate i messaggi di warning.
Nel sito Microsoft Support c'è la soluzione anche per server WINS.

Ora, se nel servizio di Routing e Accesso Remoto avete impostato dei filtri per connessione Internet, lo avrete fatto certamente sull'interfaccia interna, perchè su quella esterna (connessa al router ADSL) impostare dei filtri significa bloccare la connettività in uno o in un altro verso, inoltre questa è l'interfaccia su cui è attivo il NAT, per cui se si filtrano alcune porte e l'IP esterno del server, è come se i filtri sulle porte non ci fossero, perchè il NAT lavora considerando i filtri tutti allo stesso livello.
Per ovviare al problema basta quindi aggiungere ai filtri interni (l'interfaccia che non ospita il NAT) l'indirizzo IP interno del server. Se ad esempio i filtri sono impostati su quelli in uscita, allora bisognerà aggiungere questa voce:
Rete di Origine: 192.168.0.1 (è, ad es., l'ip del server interno)
Net Mask: 255.255.255.255 (perchè stiamo parlando di machera di rete, non di sottorete).
Dare OK.

In questo modo il server apre tutte le sue porte all'interno della rete, pur continuando a filtrare il traffico Internet che proviene dalla scheda esterna. I filtri saranno tanto più invisibili quanto sarete precisi nell'aprire tutto il set di porte necessarie; inoltre è consigliabile lasciare passare tutte le comunicazioni ICMP.

venerdì, gennaio 04, 2008

IIS, FastCGI e PHP


Da diverso tempo orami Microsoft mette e disposizione per chi vuole far girare il PHP su IIS 6.0 l'estensione FastCGI, che permette di far girare in modo veloce e senza intoppi le pagine PHP sul server.

Il modello CGI infatti, oramai superato, generava nel server un nuovo processo per ogni operzione che le pagine PHP chiedevano al web server, e quindi risultava molto lento e dispendioso come risorse.
Installare il PHP come ISAPI invece faceva sì che l'interprete PHP girasse come un thread interno a IIS. Peccato però che alcune estensioni del PHP non siamo thread-safe, il che può generare l'interruzione del servizio web.

Per ovviare a tutti questi inconvenienti ecco FastCGI, che unisce performance a stabilità permettendo ad un processo stile CGI di restare attivo per le richieste successive.
L'installazione non è molto intuitiva e per questo pubblico una breve setup guide.
Prima di tutto scaricare ad installare il pacchetto ed estrarre il PHP in C:\php. Poi posizionarsi in "C:\windows\system32\inetsrv\" e dal prompt dei comandi eseguire una per una queste istruzioni:


  • cscript fcgiconfig.js -add -section:"PHP" -extension:php -path:"C:\PHP\php-cgi.exe"

  • cscript fcgiconfig.js -set -section:"PHP" -InstanceMaxRequests:10000

  • cscript fcgiconfig.js -set -section:"PHP" -EnvironmentVars:PHP_FCGI_MAX_REQUESTS:10000

che vanno a moificare il file fcgiext.ini nella stessa cartella, configurando l'estensione per tutti i siti web. E' anche possibile configurare FastCGI per un solo sito di IIS; per questo consultare la guida in linea.


Ora dobbiamo dire a IIS che le pagine con estensione PHP vengano date a FastCGI. Per fare ciò avviare inetmgr.exe e dalle proprietà del sito principale cliccare prima su Home directory nelle schede e poi nel pulsante Configurazione... . Nella schermata che appare cliccare su Aggiungi... e come eseguibile dare "C:\windows\system32\inetsrv\fcgiext.dll", come estensione ".php", come verbi "GET,HEAD,POST" e dare ok, avendo cura di controllare che i due check a fine maschera siano selezionati.


Ora non rimane che impostare il file C:\php\php.ini come già pubblicato più volte in questo blog, lasciando però commentata la voce cgi.redirect.
Per provare l'installazione basta usare il solito:

Buon lavoro.

mercoledì, gennaio 02, 2008

Virtual Cluster 2008!

Torno ad occuparmi un po' dei cluster...
Riguardo alle tecnologie di parallelizzazione di un programma, si ricorda che questo deve essere adatto allo scopo, e cioè deve presentare la possibilità di dividere l'onere computazionale in più threads (il processo è l'immagine in RAM del programma, mentre il thread è l'unitò granulare in cui un processo è suddiviso) i quali, per farla breve, possono essere distribuiti su più unità logiche.

Per chi inoltre si domandasse il perchè di riscrivere un programma per l'esecuzione in cluster, basti sapere che un processo, per essere eseguito dopo essere stato compilato con un compilatore "comune", ha bisogno di "andare a parare" su una singola unità logica che lo gestisca. La parallelizzazione è attuata attraverso l'implementazione ad esempio di un protocollo di comunicazione fra diverse macchine, come le librerie MPI. Le virtual machine che girano in cluster non esistono appunto per questo motivo e per il fatto che "emulare" un processore farebbe colare a picco le prestazioni (provate a installare Virtual PC sopra una macchina virtuale in Vmware e poi raccontatemi...).

Tornando a noi, mi occuperò in questo articolo di definire degli scenari per l'esecuzione di codice parallelo attraverso l'uso (e quindi la preventiva costruzione) di cluster adatti allo scopo.
Fra le infinite possibilià offerte dal mercato dei software e dal mondo OSS, mi sento di portare all'attenzione due di queste, caratterizzate prevalentemente da facilità e velocità di implementazione. Parto inoltre dal presupposto che il parco macchine usato per il cluster sia un ambiente Windows, con pc relativamente recenti e collegati con Ethernet 10/100, scenario molto tipico in aziende e istituti di educazione e/o ricerca).

Il primo scenario proposto prevede la costruzione di una macchina SMP (Symmetric Multi-Processing, che è il modo per mettere più CPU in parallelo usato dai recenti processori multi-core) con OpenMOSIX, progetto purtroppo non più seguito dagli sviluppatori dal 1° dicembre 2007. L'idea è quella di eseguire in Vmware Server 1.0 (che è gratuito) il sistema operativo ClusterKNOPPIX o ParallelKNOPPIX, che costituirà il nodo principale del cluster. Per usare tutte le altre macchine Windows, si può installare e configurare coMosix, che è bene configurare prima di fare il boot della virtual machine con Linux. Per la configurazione seguire il tutorial nel sito del pacchetto (niente di particolarmente difficile).
Abbiamo così a disposizione una macchina SMP in Linux, il tutto senza intaccare le installazioni Windows. Questo scenario è efficace fino a 16 macchine, dopodichè le prestazioni calano in picchiata. Inoltre è possibile usare la configurazione di rete già esistente. Consiglio di avviare manualmente (in locale o in remoto) il servizio di coMosix, per evitare che il processore fisico di ogni machcian venga occupato inutilmente se Linux (nodo principale del cluster) non è in funzione (questo per evitare usi indesiderati della CPU host, perchè la rete usata dal cluster è la stessa di quella fisica e inoltre il "padre" di coMosix, coLinux, occupa permanentemente una CPU su due in Pentium 4).
Da ricordare infine che il cluster così costruito è una macchina SSI (cfr. tassonomia di Flynn), e può essere usato con programmi che sono compilati per CPU multicore.

Il secondo scenario proposto riguarda la recente possibilità di usare il nuovo Windows Server Cluster Edition (o il nuovo Windows 2008 HPC), che gira solo su piattaforme a 64 bit. L'idea qui è di distribuire in ogni macchina Virtual Server 2005 R2 Sp1 (la versione Standard fa al caso nostro) e una installazione virtuale del sistema operativo suddetto. Va da sè che le macchine host devono avere il sistema operativo a 64 bit per poterlo ospitare, e le prestazioni migliori sono raggiunte se hanno anche 4GB di RAM, di modo che possiamo attivare da BIOS la virtualizzazione assistita tramite hardware. In questo modo ancora una volta non si intacca l'installazione e la configurazione delle macchine host, anche se la procedura è più onerosa in termini di tempo. Per chi avesse tutte le installazioni di Windows a 32 bit, allora la scappatoria sta nel fatto di usare Vmware per l'emulazione, che permette di installare anche OS a 64 bit se il processore fisico supporta queste istruzioni). I vantaggi della piattaforma Microsoft sono la maggior scalabilità e le migliori prestazione del cluster, che differisce da OpenMOSIX per efficienza e sistema di distribuzione del carico (è molto simile ad un grid). Conviene preparate un'immagine quorum del disco in formato VHD da distribuire fra le macchine, magari con SysPrep per eseguire il mini-setup iniziale. L'emulazione va fatta con due schede di rete virtuali, una che comunica con l'esterno al solo scopo di raggiungere il controller di dominio esistente in azienda, e l'altra, con sottorete diversa, per le comunicazione del cluster. Per coloro i quali la sicurezza del cluster non è un problema, basta la rete locale normale (se il cluster però è di tipo load balancing o fail-over, separare le interfacce è consigliato). Una volta terminata la distribuzione, seguire i wizard di installazione del cluster, particolamente semplici e intuitivi. Credo appaia ovvio che questo tipo di installazione pesa molto di più nelle macchine host di quella precedente, ma ha il vantaggio, per alcuni forse fondamentale, di poter eseguire codice parallelo in macchine Windows.

Infine segnalo per completezza la Sun N1 Grid Engine, che ha prestazioni vicine al secondo scenario, e altri modi per usare Windows in cluster come quello offerto dalla software house Digipede.

Per chi come me fosse interessato a far girare Matlab in un cluster, allora è possibile usarlo, nella edizione per Linux, con il primo scenario, poichè dalla versione 2007a Matlab supporta gli SMP (particolarmente adatta al calcolo in parallelo è l'inversione di matrici); dato comunque che il riconoscimento dei processori disponibili nel cluster non è così automatico, alcuni suggeriscono di usare tool come JavaParty o JavaPorts per eseguire vecchie versioni di Matlab in parallelo. Indico anche altre possibilità in Matlab a livello di codice, come la Distributed Computing Engine (integrata), oppure le librerie MPICH per Matlab.

sabato, dicembre 15, 2007

LCS 2005 - 2 - Web Access

Il software LCS funziona in abbinata con Live Communicator 2005, un client che è molto simile a Windows Live Messenger, e permette di aggiungere gli utenti conoscendone il proprio indirizzo mail interno all'azienda (quello in Active Directory), o anche cercandoli con nome e cognome per la versione Enterprise del server.
Per chi volesse implementare un servizio web di accesso, solo testuale, senza audio e video, la Microsoft mette a disposizione il pacchetto Communicator Web Access (CWA), multilingua e indipendente dalla lingua del server. Per utilizzarlo è necessario aggiornare il server al Sp1 con la stessa procedura per l'installazione.
In pochi minuti la procedura di setup è completata e possiamo procedere alla configurazione: viene aggiunto dal setup un nuovo sito in IIS che servirà per gestire il servizio. Configurare debitamente le porte di accesso (la modalità di accesso può essere SSL o HTTP in chiaro, ma non entrambe).
La configurazione avviene attraverso uno snap-in di mmc che è comodo utilizzare insieme allo snap-in di LCS, dato anche che quello installato dal setup di default non funziona.

Per la comunicazione fra OWA e LCS ci serve un certificato Mutual TLS, che bosognerà generare.
Per crearlo, se avete Windows Server 2003 e il servizio Certificati installato, seguite questi passi:
  1. dal server aprire http://nome_server/certsrv ;
  2. cliccare pagina dopo pagina su: Request a certificate -> Advanced certificate request -> Create and submit a request to this CA;
  3. immettete i dati richiesti, e come nome certificato (nome container) immettere nome_server.dominio (cioè l'FQDN del server), e in Certificate type selezionare Other... e immettere il seguente OID:
    1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2
    senza spazi fra le cifre;
  4. inviare il certificato e poi approvarlo dalla mmc del server certificati, cliccando col desto e poi Emetti;
  5. ritornare al sito del passo 1 e scaricare il certificato;
  6. installarlo e usarlo come certificato Mutual TLS per far comunicare LCS e OWA.
Per autorizzare i client Live Communicator all'accesso, il certificato deve essere installato nel pc client sotto la cartella "Autorità di certificazione attendibili".

Live Communications Server 2005 - 1 - Installazione

Comincia qui il pacchetto di articoli per l'installazione e la manutenzione di Microsoft Live Communications Server 2005, un prodotto molto interessante per la messaggistica aziendale e la video conferenza (per il quale c'è anche un prodotto più specifico: Live Meeting).
La ragione per cui scrivo una guida minimale per questo software è che la documentazione relativa è scarsa, non completa e solo in lingua inglese. La versione 2005, già sorpassata dalla 2007 uscita quest'anno, è ancora valida per le sue prestazioni in termini di requisiti di sistema e perchè lavora molto bene con Windows Server 2003, ancora per qualche mese la punta di diamante dei sistemi operativi server di casa Microsoft.

Vediamo ora l'installazione. Dapprima bisogna scegliere fra la versione Standard e quella Enterprise, che differiscono per la portata massima di utenti (la Standard arriva a 1024) e per la necessità della Enterprise di avere un servizio SQL Server 2000 (almeno Sp3) in qualche server della rete aziendale. La versione Standard invece installerà nello stesso server su cui gira il servizio SQL Desktop Engine, più leggero e a configurazione zero.
Una volta scelta la versione più adatta, all'autorun del CD ci si accorge che non esiste un vero e proprio setup, ma si deve seguire la guida per il deploy, anche se l'installazione è singola.
Dopo diverse operazioni guidate su Active Directory, finalmente viene installato il servizio e per finire bisogna attivarlo. La porta TCP per le comunicazioni in chiaro è la 5060, mentre per quelle SSL si usa la 5061 di default. Configurare i firewall di conseguenza.